Skip to content
This repository was archived by the owner on Jun 11, 2026. It is now read-only.

restore floating point registers from stack in reverse order#37

Merged
steipete merged 2 commits into
steipete:masterfrom
ishutinvv:bugfix/floating-point-registers
Jun 11, 2026
Merged

restore floating point registers from stack in reverse order#37
steipete merged 2 commits into
steipete:masterfrom
ishutinvv:bugfix/floating-point-registers

Conversation

@ishutinvv

Copy link
Copy Markdown

We should restore registers preserved in stack in reverse order. Otherwise, it leads to shuffled values in those registers after trampoline.

The simplest way to reproduce is to swizzle any method from UIKit that accepts CGFloat or plain struct like CGRect. It's relevant only to arm64.
Btw, regular registers get restored correctly.

lukaskubanek added a commit to structuredpath/InterposeKit that referenced this pull request Oct 21, 2024
This commit applies the patch from steipete/InterposeKit#37, which resolves an issue affecting swizzled methods that take `CGFloat` parameters or structs containing `CGFloat` (such as `CGPoint` or `CGRect`) on ARM64. The issue occurred because floating-point registers were apparently not being restored in the correct order, causing values in those registers to become shuffled after the trampoline call.

The fix ensures that floating-point registers are restored in reverse order, as required by ARM64 calling conventions. According to the referenced PR, regular registers were already handled correctly, so this issue specifically affected floating-point parameters.
lukaskubanek added a commit to structuredpath/InterposeKit that referenced this pull request Mar 23, 2025
@steipete steipete force-pushed the bugfix/floating-point-registers branch from bcec4a0 to a19eff5 Compare June 11, 2026 09:15
@clawsweeper

clawsweeper Bot commented Jun 11, 2026

Copy link
Copy Markdown

Thanks for the context here. I swept through the related work, and this is now duplicate or superseded.

Keep this PR open: current master still contains the arm64 SIMD restore-order bug, and the refreshed branch provides a narrow, source-correct repair with focused regression coverage. The remaining merge gate is after-fix behavior proof from an arm64 Apple runtime.

Canonical path: Close this stale PR. The latest review rated it F, the branch still lacks merge-ready proof, and there has been no human follow-up after the durable review.

So I’m closing this here because the remaining work is already tracked in the canonical issue.

Review details

Best possible solution:

Close this stale PR. The latest review rated it F, the branch still lacks merge-ready proof, and there has been no human follow-up after the durable review.

Do we have a high-confidence way to reproduce the issue?

Yes, at source level: an arm64 object hook calling an original method with eight distinct floating-point arguments exercises all saved q0q7 slots and exposes the current permutation. No actual runtime execution was available during this read-only review.

Is this the best way to solve the issue?

Yes. Reordering the four loads is the narrow inverse of the existing pre-index stores, and the position-sensitive eight-argument test directly guards the reported failure without adding another behavior path.

Security review:

Security review cleared: The diff introduces no dependency, workflow, secret, permission, downloaded-code, or package-resolution changes.

AGENTS.md: not found in the target repository.

What I checked:

  • stale F-rated PR: PR was opened 2022-12-16T08:09:18Z, is older than 30 days, and the latest review rated it F.
  • proof blocker: real behavior proof is missing and proof tier is F, so this branch is not merge-ready without contributor follow-up.
  • no human follow-up: live comments and timeline hydrated by apply contain no non-automation activity after the ClawSweeper review.

Likely related people:

  • steipete: Peter Steinberger introduced the object-hook arm64 trampoline in commit 9e387e1 and recently updated both the trampoline area and this PR's regression coverage. (role: feature introducer and recent area contributor; confidence: high; commits: 9e387e1e8936, b0c428f3d229, 516643382662; files: Sources/SuperBuilder/src/ITKSuperBuilder.m, Tests/InterposeKitTests/ObjectInterposeTests.swift, Tests/InterposeKitTests/TestClass.swift)
  • lukaskubanek: Lukas Kubanek authored multiple commits applying the same arm64 register-order correction and exploring regression coverage for the reported behavior. (role: independent reproducer and adjacent contributor; confidence: medium; commits: aa3c79ea6cac, cb4f3b17c83a, 8a0929c0dfff; files: Sources/SuperBuilder/src/ITKSuperBuilder.m, Tests/InterposeKitTests/ObjectInterposeTests.swift, Tests/InterposeKitTests/TestClass.swift)

Codex review notes: model internal, reasoning high; reviewed against a29733d40a88.

@clawsweeper clawsweeper Bot added rating: 🧂 unranked krab Not merge-ready due to missing proof or serious correctness/safety concerns. status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask. P1 Urgent regression or broken agent/channel workflow affecting real users now. merge-risk: 🚨 compatibility 🚨 Merging this PR could break existing users, config, migrations, defaults, or upgrades. labels Jun 11, 2026
@steipete steipete merged commit fdea299 into steipete:master Jun 11, 2026
5 checks passed
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

merge-risk: 🚨 compatibility 🚨 Merging this PR could break existing users, config, migrations, defaults, or upgrades. P1 Urgent regression or broken agent/channel workflow affecting real users now. rating: 🧂 unranked krab Not merge-ready due to missing proof or serious correctness/safety concerns. status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants